AWS 認定デベロッパー – アソシエイト(DVA-C01)対策として学んだことをまとめてみた

もっさん

2020.10.09

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。オペレーション部のもっさんです。
2020/09/15に AWS 認定デベロッパー – アソシエイト(DVA-C01)を受験し、合格しました。
今回も受験までの流れや、勉強に利用した書籍・資料を記録として書き留めておきます。
また、公式資料を読み解く際に覚えておきたい用語についてもまとめました。

AWS 認定デベロッパー – アソシエイト(DVA-C01)とは

AWS認定のうちの1つで、開発者の役割をもつ人に向けた試験で、AWSベースのアプリケーションの開発や保守に関する知識を問われます。
レベルはアソシエイト(少なくとも1年以上の経験があることが推奨)に位置付けられています。
DVA試験を受験する際、別の試験への合格やトレーニングの受講といった必須前提条件はありません。

試験の詳細や試験ガイドは、公式サイトより確認ができます。
勉強を始める前に一読しておきましょう。
AWS 認定デベロッパー – アソシエイト

受験までの流れ

書籍のDVA対策の部分を読む
公式の模擬試験を受ける
苦手なサービスのBlackbeltを重点的に読む

書籍のDVA対策の部分を読む

SAA、SOAの受験レポートでもご紹介しましたが、書籍は「AWS認定アソシエイト3資格対策～ソリューションアーキテクト、デベロッパー、SysOpsアドミニストレーター～」を利用しました。

私の場合、SOAの受験直後から勉強を開始しており、他の試験と重複するジャンルは記憶に新しかったため、書籍の中で「DVA対策として有効」と記載されている部分をまずは一周読みました。
後述の模擬試験受験後や、BlackBeltを読んでも理解が及ばなかった部分は、こちらの書籍を読み返すことで復習していきました。

公式の模擬試験を受ける

今の自分の理解度を把握するため、公式の模擬試験を受験しました。
1回につき2000円の費用がかかりますが、受験後に確認できるスコアレポートで出題分野ごとの得点率がわかります。
自分の苦手分野を効率よく克服するために、このスコアレポートと試験ガイドを照らし合わせながら、重点的に学ぶべきサービスを割り出していきました。

苦手なサービスのBlackBeltを重点的に読む

模擬試験を受験してみて、私は Elastic Beanstalk に関しての理解が足りないと感じたため、BlackBeltでサービスの概要を学び直しました。
各サービスの開発者ガイドなども、詳細なユースケースが記載されており、深くサービスを知るにはよい資料です。
ただ、BlackBeltの資料は図もふんだんに使われており、機能の振る舞いや他サービスとの連携について直感的に理解できます。
「このサービス、あんまり使ったことがないんだよなぁ……」というサービスを学ぶ際には、BlackBeltから入るのがよいと思います。

下記リンクから、各サービスの資料を閲覧することができます。
サービスによってはプレゼンテーション資料だけでなく、YouTube動画も視聴することができますので、自分の学習スタイルに合ったもので勉強してみてください。
サービス別資料 | AWS クラウドサービス活用資料集

資料を読むための前提知識

DVAの出題範囲のサービスを学ぶための資料には、AWSに限らないアプリケーションの開発・保守のための用語がたくさん出てきます。
(当たり前といえば当たり前ですが……)
私は受験当時、商用でのアプリケーション開発の経験がなかったため、まずは各サービスの資料内に出てくるこれらの用語を理解する必要がありました。
私のようにイチから……いいえ、ゼロからアプリケーション開発を学ぶレベルの方の参考になればと思い、資料内でよく出るデプロイに関する用語について簡単にまとめました。

Blue/Greenデプロイメント(またはBlue/Greenデプロイ)
できるだけ同様の環境をBlue系/Green系の2通り準備して、リクエストの宛先となる環境を切り替えるデプロイの手法です。
例えば、Blue系の環境が現在本番運用されている環境、Green系の環境がそのコピーだと仮定します。
まずは本番環境のコピーであるGreen系で、新しいバージョンのテストを実行しておきます。
十分なテストによって本番運用ができると判断されたら、Blue系へのリクエストの宛先をGreen系に切り替えます。
これにより、サービス影響が極力少ない状態でのデプロイが可能となります。
また、新環境で何か問題が発生した場合でも、リクエストの宛先を再度Blue系に戻せばよいだけなので、切り戻しによる作業負荷も抑えることができます。

ローリングアップデート
ハイパーバイザの保守経験などがある方には、馴染み深い手法かもしれません。
同じクラスタやロードバランサの配下にあるコンテナやサーバ内で、アップデートを行う対象を順次入れ替えて、1台ずつ順番にアプリケーションの変更を適用していく手法です。
こちらも、一度にすべてのコンテナやサーバへの変更を行うよりもサービス影響が少なくなります。
ただし、普段よりも少ないサーバーやコンテナ台数でサービスの提供を行い続ける状態となるため、稼働状態のものに想定外の負荷がかかった際に処理しきれなくなるリスクがあります。

インプレースアップグレード
すべてのサーバに対して、一度にアプリケーションの変更を適用する手法です。
サーバの再起動が必要な変更を適用する場合には、必ずサービスの停止が発生するため、アプリケーション変更が成功したとしても影響が大きい手法となります。
また、問題が発生した際の切り戻しも上記の2つほど簡単ではありません。

デプロイの手法に関しては、下記のブログが参考になります。